termattrs() returns a chtype mask, but GH-134327 routed it through an int to check
for ERR. On a terminal that advertises A_ITALIC, the topmost bit of a 32-bit mask,
the result comes back negative and the attribute functions reject it:

>>> curses.termattrs()
-2130771968
>>> curses.term_attrs()          # the same bits, unsigned
2164195328
>>> curses.newwin(1, 1).attrset(curses.termattrs())
OverflowError: can't convert negative value to unsigned int

It now returns the mask unsigned, the same way getattrs(), slk_attr() and
term_attrs() already do. baudrate(), the macro's only other user, really does return
a status, so it keeps the ERR check.

The test drives newterm('xterm-256color') over a pseudo-terminal rather than using
$TERM, which on CI is usually linux and advertises no italic, so a signed result
would slip through. It fails without the change.

3.15 has the same bug, so this needs a backport. 3.14 is fine.

• Issue: curses.termattrs() returns a negative value on italic terminals #154874